home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 1
/
Cream of the Crop 1.iso
/
PROGRAM
/
PROTO212.ARJ
/
PROTOF.MAN
< prev
next >
Wrap
Text File
|
1992-01-14
|
55KB
|
1,365 lines
1 Introduction et avertissements 1
1.1 Pourquoi utiliser un extracteur 1
1.1.1 Mise en service d'une librairie avec prototypes invalides 1
1.1.2 Validation implicite du fichier d'inclusion 1
1.1.3 Révision des clients d'un service 2
1.2 Certains compilateurs peuvent extraire les prototypes 2
1.2.1 Un compilateur peut oublier des prototypes 2
2 Limites de la version d'évaluation 2
2.1 Production automatisée de sommaire alphabétique 3
2.2 Production d'un index permuté 3
2.3 Production et entretien d'un historique des fonctions 3
3 Spécifications et opération 3
3.1 Principes généraux 4
3.1.1 Systèmes, clients, et fournisseurs en programmation 4
3.1.2 Déclaration de fonction (prototypes) et définition 4
3.1.2.1 Utilité des déclarations de fonctions 5
3.1.2.2 Stratégie d'utilisation des prototypes 5
3.1.2.3 Composition du fichier d'inclusion 5
3.2 ANSI C et C++ supportés 6
3.3 Mot-clés ajoutés pour automatiser l'opération de 6
l'extracteur
3.3.1 Définition des mots clés supplémentaires 6
3.4 Options de la ligne de commande 6
3.4.1 @fichier : fichier contenant des paramètres de ligne de 7
commande
3.4.1.1 Exemple de localisation de fichiers de commandes 7
3.4.1.2 @ spécifié sans fichier 8
3.4.2 -a : Accès par défaut au fonctions membres (C++) 8
3.4.3 -b : Mise à jour d'un fichier C++ à partir d'un fichier .pm 8
3.4.3.1 Exemple d'utilisation de l'option -b 9
3.4.3.2 Controle de la distribution des prototypes de fonctions 9
membres
3.4.4 -c : composition de l'extraction 9
3.4.4.1 Le verbe export : extension au C 10
Ajout du verbe export au langage C 10
Utilité du verbe export 10
Le verbe _export 10
3.4.4.2 Combinaison de l'option -c et -f dans une seule session 11
3.4.4.3 Paramètre 'i' de l'option -c: Référence inverse 11
3.4.4.4 Paramètre 'd' de l'option -c: Prototypes et documentation 11
3.4.4.5 Corrections au prototypes avant la génération 11
Fonctions sans type de retour 12
Paramètres sans type 12
Fonctions sans paramètre 12
3.4.5 -C : Ne traite pas les commentaires imbriqués 12
3.4.6 -d : Définition de symbole sur la ligne de commande 12
3.4.7 -e : Ferme un fichier résultat 13
3.4.7.1 Protection contre le double traitement durant une session 13
Fichiers sources répartis dans deux répertoires 13
3.4.8 -f/+f : identification d'un fichier résultat 13
3.4.8.1 Combinaison de l'option -c et -f dans une seule session 14
3.4.9 -h : fichier de prototypes C++ à décomposer 14
3.4.10 -i : Mode incrémental 14
3.4.11 -I : Répertoire de recherche pour les fichiers d'inclusion 15
3.4.12 -k : Renomme les mot-clés reconnus par l'extracteur 15
3.4.13 -l : Spécification d'un nom alternatif pour l'option -h 15
3.4.14 -m : Sélectionne une méthodologie particulière 16
1
3.4.14.1 Répertoires alternatifs pour l'exportation des fichiers 16
résultat
3.4.15 -o : Nom alternatif pour l'option -m 16
3.4.16 -p : Activation de l'extraction pour les fichiers suivants 16
3.4.16.1 Exemple d'utilisation des options -x et -p 16
3.4.16.2 Protection contre le double traitement durant une session 17
3.4.17 -P : activation du préprocesseur 17
3.4.17.1 Traitement des #define même lorsque le préprocesseur n'est 17
pas actif
3.4.17.2 Traitements des #if, #ifdef, ... sans -P 17
3.4.18 -s : opération silencieuse 18
3.4.19 -t : lecture du source à traiter sur la console 18
3.4.20 -v : Liste des fichiers traités 18
3.4.21 -x : exclusion d'un groupe de fichier 18
3.4.21.1 Exemple d'utilisation des options -x et -p 18
3.4.21.2 Protection contre le double traitement durant une session 18
3.4.22 Macros et Caractères spéciaux 19
3.4.22.1 $ : Nom du répertoire courant 19
3.5 Combinaisons invalides d'options 19
3.6 Stratégie d'utilisation de l'extracteur 19
3.6.1 Convention d'utilisation: Avertissement au lecteur 19
3.6.2 Le répertoire (directory) est la base de l'organisation d'un 19
système
3.6.3 Convention de noms pour les fichiers d'inclusion 20
3.6.4 Fichiers générés localement 20
3.6.5 Fichiers exportés pour les clients 20
3.6.5.1 Le verbe export : extension au C 21
3.6.6 Unicité du fichier d'inclusion 21
1 Introduction et avertissements
L'extracteur de prototypes automatise et agrémente une
partie du travail d'un programmeur en langage ANSI C et C++
2.0. Il supporte aussi la syntaxe de déclaration de
fonctions K&R.
Une version existe pour MSDOS (PCDOS) version 3 et plus,
pour SCO XENIX version 2.3 (UNIX système V.3.2) et pour SUN
SPARC (Sunos).
Ce manuel s'applique intégralement dans les trois
environnements. Toutefois, le séparateur / a été choisi pour
la spécification de fichiers dans le manuel. La version
MSDOS du logiciel reconnaît le séparateur \ et non pas /.
1.1 Pourquoi utiliser un extracteur
L'utilisation d'un extracteur de prototypes est facultative.
On peut inscrire manuellement les prototypes dans un fichier
d'inclusion. Le langage ANSI C tolère l'absence de prototype
pour conserver une compatibilité avec la version K&R du
langage. Le langage C++ commande l'usage de prototypes.
Nous ne tenterons pas de démontrer l'importance des
prototypes en programmation. Nous tenterons de démontrer
pourquoi une extraction automatique par un outil spécialisé
est requise.
1.1.1 Mise en service d'une librairie avec prototypes invalides
En révisant une librairie, on doit parfois ajouter des
fonctions, en éliminer et en modifier. Lorsqu'on livre une
nouvelle version d'une librairie, la fiabilité des
prototypes est essentielles. Souvent des problèmes avec la
nouvelle version seront détectés par une autre équipe de
programmeurs, qui seront confondus par le fait que leur
projet compile parfaitement mais n'exécute pas bien.
En C ce problème peut prendre un temps considérable à
régler. La nouvelle version de la librairie sera la dernière
à être soupçonnée. En C++ le problème sera détecté à l'étape
du "link". Cela introduira une perte de temps, et surtout
une insatisfaction évidente.
1.1.2 Validation implicite du fichier d'inclusion
Un truc simple permet de vérifier que les prototypes
inscrits dans un fichier d'inclusion sont valides. Il s'agit
d'inclure ce fichier dans chacun des sources qui déclarent
ces fonctions. Une simple recompilation permettra de
comparer les prototypes à la déclaration originale.
Cette méthode a toutefois un lacune. Elle ne détecte pas
l'absence d'un prototype, ni ne détecte la présence de
prototypes de fonctions périmées.
1
En C++, cette méthode est simplement inutile, car plusieurs
fonctions peuvent porter le même nom et posséder des
arguments totalement différents.
1.1.3 Révision des clients d'un service
On doit parfois modifier les arguments d'une fonction
utilisée dans divers autre sous-système. Généralement avant
de faire cela, le programmeur localisera toutes les usages
de cette fonction et les modifiera en conséquence.
Cela se fera souvent à l'aide du programme GREP. Cette
méthode n'est toutefois pas garantie. Il se peut que
certains systèmes client soit innaccessibles à GREP (pas sur
le même ordinateur), ou simplement inconnus du programmeur.
Notez qu'en C++, la détection des usages d'une fonction
membre à l'aide de GREP est pratiquement voué à l'échec. Il
faudra utiliser des références croisés ou autre gadgets pour
déterminer qui se sert d'une fonction.
Seul une recompilation de ces systèmes clients exposera les
utilisations erronés. Cette recompilation pourra se faire
plusieurs semaines, et même plusieurs mois après la mise en
service de la librairie. La validité des prototypes est la
seule assurance.
1.2 Certains compilateurs peuvent extraire les prototypes
Certains compilateurs ont une option pour extraire les
prototypes tout en compilant. Une telle option pose
généralement des problèmes de performance et n'est utilisée
qu'en dernier recours.
L'extraction des prototypes doit être réalisée avant la
compilation; des prototypes valides sont essentiels. Si un
compilateur est utilisé, deux sessions de compilation seront
nécessaires; une pour extraire les prototypes et une autre
pour compiler.
1.2.1 Un compilateur peut oublier des prototypes
Si on utilise un compilateur pour extraire des prototypes,
on peut se retrouver avec un problème de taille. Le
compilateur peut stopper délibérément la compilation d'un
source parce qu'ils rencontrent trop d'erreurs. Les
prototypes des fonctions qu'il n'a pas compilé ne seront pas
générés.
En fait plusieurs des erreurs rencontrés par le compilateur
seront causés par l'absence de prototypes valides.
2 Limites de la version d'évaluation
Le présent manuel explique toutes les options de
l'extracteur.
2
Certaines options ne sont pas disponibles dans la version
d'évaluation. La licence explique comment on peut obtenir
une version complète.
En plus d'obtenir la dernière version du logiciel, l'usager
recevra d'autres utilitaires. Ils sont documentés ici. La
liste présentée ici est sujet à changement sans préavis.
2.1 Production automatisée de sommaire alphabétique
Un utilitaire produit un sommaire. Pour chaque fonction, une
ligne de commentaires est extraite du source. La ligne
choisie est basée sur une convention minimale.
Le fichier produit est un texte dont le format est:
fonction_a: description sommaire de fonction_a
...
fonction_z: description sommaire de fonction_z
La première ligne du bloc de commentaire précédant la
déclaration d'une fonction est extraite.
2.2 Production d'un index permuté
A partir du sommaire alphabétique, un index basé sur les
mots clés de la description est produit. Pour un sommaire
comportant les deux fonctions suivantes,
bouton_creation: création et initialisation d'un bouton
bouton_annule: efface et élimine un bouton de la mémoire
Chacun des mots significatifs de la description seront tour
à tour utilisés comme clé de tri. Il devient possible de
localiser une fonction en utilisant différents mots clés
(efface, élimine, bouton, mémoire, création, ...).
2.3 Production et entretien d'un historique des fonctions
Un fichier sera entretenu à partir du fichier de prototypes
et documentation produit par l'extracteur.
L'historique est un fichier texte. Il contient une
description de chaques fonctions accompagnées de sa date de
création ou de révision. A chaque fois que le système est
révisé, le fichier d'historique est mis à jour en ajoutant
les fonctions qui ont été révisées (basé sur une comparaison
ASCII du prototype documenté de la fonction), les nouvelles
fonctions et en notant les fonctions éliminées.
Ce fichier permet à un programmeur de localiser rapidement
les nouveaux services, les services révisés et les services
qui ont été éliminés.
3 Spécifications et opération
3
Description des caractéristiques de l'extracteur de
prototypes ANSI C. Ce manuel contient un guide d'opération
mais aussi des suggestions sur l'application de cet outils.
3.1 Principes généraux
L'extracteur s'applique autant aux projets de quelques
fichiers sources qu'aux projets d'envergure: plusieurs
centaines de fichiers répartis en plusieurs répertoires.
3.1.1 Systèmes, clients, et fournisseurs en programmation
Tout au long de ce manuel, nous utiliserons les mots
systèmes, clients et fournisseurs.
Un système (package) est une collection de fonctions
intimement liées permettant la réalisation d'une tâche
spécialisée. Un exemple de système est la série de fonctions
str____() livrée avec la majorité des compilateurs C
(strcmp, strlen, strcpy, strchr, ...). Ces fonctions
proposent généralement un certain nombre de conventions ou
modèles à l'usager (le programmeur). Le système est un
fournisseur, et les sources qui le composent sont des
membres du système.
Le programmeur qui utilise ces fonctions pour réaliser une
nouvelle fonction est un client de ce système. Tout au long
de ce document, c'est la relation entre ces nouvelles
fonctions et les fonctions d'un système qui sera étudiée.
Les fonctions créées à partir d'autres fonctions, sont des
clientes. Ces "autres" fonctions sont des fournisseurs. Ces
dernières font généralement partie d'un système (parfois
appelé librairie).
3.1.2 Déclaration de fonction (prototypes) et définition
Une différence majeure entre le langage ANSI C et le C
original (K&R) est le concept de déclaration de fonction
(function prototype). C'est la possibilité de décrire de
façon formelle l'interface d'une fonction sans fournir le
corps de cette fonction.
Soit la définition de la fonction max():
int max(int a, int b)
{
if (a<b) return (b);
return (a);
}
Soit la déclaration de la fonction max():
int max (int a, int b);
4
3.1.2.1 Utilité des déclarations de fonctions
La déclaration d'une fonction permet d'informer le
compilateur sur l'interface d'une fonction, sans fournir la
fonction au complet. Cela permet de créer une fonction dans
un fichier source et de l'utiliser dans un autre en toute
sécurité.
Le compilateur aura toutes les informations pour déterminer
si l'utilisation (appel de la fonction) faite de cette
fonction est conforme. Il pourra vérifier le nombre
d'arguments ainsi que le type de chacun. Les appels à la
fonction max() seront tous signalés par le compilateur.
Evidemment un prototype de la fonction devra être fourni au
début du source.
int max(int a, int b);
...
char *pt = max ("xyz","zzz"); /* arguments invalides */
int m = max (1,2,3); /* nombre d'arguments invalide */
3.1.2.2 Stratégie d'utilisation des prototypes
Généralement on placera dans un fichier d'inclusion (*.h)
les prototypes de toutes les fonctions composant un système
ou librairie. Plusieurs fichiers d'inclusion fournis avec le
compilateur que vous utilisez contiennent des prototypes de
fonctions.
Les fonctions clientes (utilisant cette librairie) devront
inclure ce fichier d'inclusion au début du source.
exemple:
#include <string.h>
...
char *pt = strlen("....."); /* strlen() est déclaré dans string.h */
3.1.2.3 Composition du fichier d'inclusion
Le fichier d'inclusion associé à un système ne contiendra
pas nécessairement les prototypes de toutes les fonctions
contenues dans ce système.
Les fonctions "static" ne seront pas incluses, puisqu'elles
ne sont pas accessibles. Certaines fonctions internes non
plus, puisque souvent, elles ne sont ni documentées, ni
utilisables aisément par les sources clients d'une
librairie.
5
Un fichier d'inclusion est donc créé avec le client en tête.
Un programmeur peut créer deux fichiers d'inclusion pour un
système. Un sera utilisé par les fonctions membres et
l'autre par les fonctions clientes. L'extracteur permet de
construire sélectivement des fichiers d'inclusion.
3.2 ANSI C et C++ supportés
L'extracteur reconnait la syntaxe C et C++. Aucune option
n'est requise. Quelques options permettent de traiter
spécifiquement certains déclarations tel les fonctions
membres C++.
3.3 Mot-clés ajoutés pour automatiser l'opération de
l'extracteur
Le langage C++ ne permet pas d'extraire les prototypes d'une
façon complètement automatique. Pour sa part le langage C
possède un concept rudimentaire de controle de l'accès.
Sept mot-clés sont interprétés par l'extracteur pour
complètement controler la génération des prototypes à partir
du source.
export C et C++
_export C et C++
PRIVATE C++
PUBLIC C++
PROTECTED C++
STATIC C++
VIRTUAL C++
3.3.1 Définition des mots clés supplémentaires
Les mots clés export,_export,PRIVATE,PROTECTED,PUBLIC et
VIRTUAL ne sont pas supportés par plusieurs compilateurs C
et C++. On devra fournir au préprocesseur une définition
nulle pour chacun de ces mot-clés.
Un définition nulle peut s'exprimer directement sur la ligne
de commande (généralement option -d du compilateur) ou dans
un fichier d'inclusion.
#define export
#define _export
#define PUBLIC
#define PRIVATE
#define PROTECTED
#define VIRTUAL
Notez que _export est supporté par certain compilateurs.
3.4 Options de la ligne de commande
6
Cette section décrit la liste des options spécifiables sur
la ligne de commande. Une option est spécifiée par un '-'
suivie d'une lettre suivie optionnellement d'une séquence de
caractères non blancs:
-x
-ceoi
-ffichier.nar
3.4.1 @fichier : fichier contenant des paramètres de ligne de
commande
Si un paramètre de la ligne de commande débute par @, il
sera interprété comme un nom de fichier. Ce fichier
contiendra lui-même d'autres paramètres qui seront
interprétés.
Le fichier peut être spécifié avec un répertoire ou non. Si
le fichier est spécifié avec un répertoire, ce répertoire et
ses ancêtres seront utilisés jusqu'à ce que le fichier soit
localisé.
Si aucun répertoire n'est spécifié, le répertoire courant
sera consulté, et ses ancêtres ensuite.
Ce mécanisme de localisation permet d'écrire un seul fichier
qui sera applicable à plusieurs répertoires. Il permet aussi
d'écrire un fichier de paramètres qui sera spécifique à un
répertoire.
3.4.1.1 Exemple de localisation de fichiers de commandes
Soit les répertoires:
/usr/prj1/liba
/usr/prj1/libb
/usr/prj1/libb/libb0
/usr/prj1/libb/libb1
/usr/prj1/libc
/usr/prj2/liba
/usr/prj2/libb
/usr/prj2/libc
Si on créé les fichiers d'option suivants.
/usr/proto.cfg
/usr/prj1/libb/proto.cfg
/usr/prj2/libc/proto.cfg
La liste suivante indique quel fichier de commande sera lu
si on applique "proto @proto.cfg" dans chaque répertoire.
7
/usr/prj1/liba /usr/proto.cfg
/usr/prj1/libb/libb0 /usr/prj1/libb/proto.cfg
/usr/prj1/libb/libb1 /usr/prj1/libb/proto.cfg
/usr/prj1/libc /usr/proto.cfg
/usr/prj2/liba /usr/proto.cfg
/usr/prj2/libb /usr/proto.cfg
/usr/prj2/libc /usr/prj2/libc/proto.cfg
/lib/prjx ici la variable d'environnement PATH
sera consultée pour localiser proto.cfg
de la même façon que les programmes
sont localisés.
3.4.1.2 @ spécifié sans fichier
Si le caractère @ apparaît seul, le fichier 'proto.cfg' sera
cherché par défaut. Il sera cherché dans le répertoire
courant. S'il n'est pas trouvé, le répertoire ancêtre sera
cherché (..). La recherche se poursuivra jusqu'à la racine
du disque.
Lorsque les fichiers proto.cfg requis sont créés et placés
aux bons endroits dans un système de répertoire, la commande
"proto @" est suffisante pour extraire les prototypes de
n'importe quel système.
3.4.2 -a : Accès par défaut au fonctions membres (C++)
Les fonctions membres (d'une classe) qui ne spécifient pas
d'accès seront déclarés "private". L'option -a permet
d'enregistrer un comportement différent.
-a0 : private
-a1 : protected
-a2 : public
L'accès d'une fonction membre se spécifie à l'aide d'un des
mots clés ajoutés PRIVATE, PROTECTED, et PUBLIC.
3.4.3 -b : Mise à jour d'un fichier C++ à partir d'un fichier .pm
Normalement, proto regroupe tous les prototypes des
fonctions membres d'une classe C++ dans un seul fichier
(voir -m0+,-m1+ et -c+). Ce fichier porte généralement
l'extension ".pm". A partir de ce fichier, les prototypes
des fonctions membres sont distribués dans les fichiers qui
contiennent les déclarations des classes. L'option -b active
cette distribution.
La syntaxe de l'option est:
-bfichier_à_réviser+fichier_pm=fichier_résultat
-bfichier_à_réviser+fichier_pm
-bfichier_à_réviser
-b
8
Si fichier_résultat n'est pas spécifié, fichier_à_réviser
sera pris comme source et destination. Si fichier_pm n'est
pas spécifié, X.pm sera choisi (X est le nom du répertoire
courant). L'option -b sans arguments sera équivalente à
-bX.hpp+X.pm où -bX.h+X.pm où X est le nom du répertoire
courant. X.h sera utilisé si X.hpp n'existe pas.
L'option -b peut être utilisé plusieurs fois (pour réviser
plusieurs fichier d'inclusion) sur la ligne de commande. Son
action ne sera déclenchée qu'après l'extraction du dernier
prototype.
3.4.3.1 Exemple d'utilisation de l'option -b
Soit la commande,
proto -c+ -fx.pm *.c -bfichier1.h+x.pm -bfichier2.h+x.pm
Le fichier x.pm sera produit. Il contiendra tous les
prototypes des fonctions membres. Ensuite les fichier
"fichier1.h" et "fichier2.h" seront édités et les prototypes
seront distribués dans la déclaration des classes dont ils
sont membres.
3.4.3.2 Controle de la distribution des prototypes de fonctions
membres
Les prototypes des fonctions membres doivent être distribués
à l'intérieur de la définition de la classe dont ils sont
membres. L'extracteur utilise une méthode simple pour
localiser l'endroit où les prototypes sont placés.
L'extracteur recherche des paires de commentaires de la
forme:
/*~PROTOBEG~ NOM_DE_LA_CLASSE */
/*~PROTOEND~ */
Les commentaires doivent être seuls sur leur ligne
respective. Tous ce qui est entre cette paire de
commentaires a été placé là par l'extracteur. Le programmeur
ne devra rien ajouter entre ces commentaires, puisque
l'extracteur annulera le contenu à chaque révision du
fichier.
3.4.4 -c : composition de l'extraction
PROTO peut extraire plusieurs informations des fichiers
sources qu'il traite. Voici la liste des informations qu'il
peut extraire avec la lettre qui servira à spécifier ces
informations.
9
e : Prototypes des fonctions export (extension au langage C).
o : Prototypes des fonctions ordinaires.
p : Prototypes des fonctions membres C++ "private".
r : Prototypes des fonctions membres C++ "protected".
s : Prototypes des fonctions static.
u : Prototypes des fonctions membres C++ "public".
+ : Prototypes des fonctions membres (C++).
d : Documentations (commentaires) autour de ces fonctions.
i : Référence inverse fonction vs source.
La commande "proto -cod *.c" extraira les prototypes avec la
documentation qui les accompagne pour tous les fichiers *.c
du répertoire courant.
3.4.4.1 Le verbe export : extension au C
Le verbe export est un ajout au langage C. A notre
connaissance aucun compilateur C ne supporte un tel verbe.
Ce verbe est présentement appliqué à la déclaration de
fonctions, mais peut aussi s'appliquer à la déclaration de
types, de constantes, de variables, etc...
Le verbe export a un usage un peu équivalent au verbe
static. Ce dernier restreint la visibilité d'un objet au
source où il apparaît. Le verbe export, au contraire,
indique que la visibilité d'un objet dépasse le cadre du
système où il est défini. Une fonction 'export' est un
service officiel offert aux clients. Une fonction ordinaire
est local au système et ne doit pas être utilisée
directement par une fonction cliente du système.
3.4.4.1.1Ajout du verbe export au langage C
En utilisant le préprocesseur, il est possible d'ajouter le
verbe export au language. On inscrit simplement la ligne
"#define export" dans un fichier d'inclusion. Ce fichier est
inclus dans les sources qui font usage du verbe.
On peut aussi définir ce verbe sur la ligne de commande à
l'aide de l'option -d du compilateur. La plupart des
compilateurs supportent une option -d de la même façon que
l'extracteur.
3.4.4.1.2Utilité du verbe export
Bien que non supporté par le compilateur, ce verbe permet de
classifier les fonctions d'un système. Cela simplifie la vie
des clients à la recherche d'un service. Généralement la
liste des fonctions offertes aux clients représente moins de
la moitié des fonctions du système. Cela simplifie autant
l'usage que l'entretien du système.
3.4.4.1.3Le verbe _export
10
Le verbe _export devient une extension populaire au language
C. Il facilite la réalisation de librairies dynamiques. Il a
sémantiquement le même rôle que le verbe export décris plus
haut. Les deux verbes sont accepté comme synonimes.
3.4.4.2 Combinaison de l'option -c et -f dans une seule session
Les options -c et -f peuvent être spécifiées plusieurs fois
sur la ligne de commande.
L'option -c établie une composition de résultat valide pour
toutes les options -f qui suivent, et ce jusqu'à la
prochaine option -c.
La commande "proto -co -fordin.h -cs -fstatic.h -cod
-finfo.h *.c" produira trois fichiers de composition
différente. On sauve du temps à générer plusieurs fichiers
simultanément.
3.4.4.3 Paramètre 'i' de l'option -c: Référence inverse
Le paramètre 'i' de l'option -c produit une référence
inverse fonction -> sources. D'un format compact, le fichier
permet de déterminer le source qui contient la déclaration
d'une fonction.
Le fichier est un texte ASCII où chaque ligne a la forme
suivante:
longueur!nom_de_la_fonction!source
Les points d'exclamation '!' sont présents dans le fichier,
comme séparateur. La longueur est la dimension (en octet) de
la ligne. Cette longueur est encodée en un seul octet. Pour
ne pas nuire à la nature 'texte' du fichier, la constante 32
est ajoutée à cette longueur.
Un format texte a été choisi pour simplifier la réalisation
de fonction de recherche. Une telle fonction peut être codée
directement à partir du langage macro de certains éditeurs.
3.4.4.4 Paramètre 'd' de l'option -c: Prototypes et documentation
Le paramètre 'd' commande l'extraction des prototypes ainsi
que des commentaires entourant la déclaration de la
fonction.
Tous les commentaires contigus qui précèdent immédiatement
la déclaration ainsi que tous rencontrés avant la première
'{' du corps de la fonction seront extrait et placés avec le
prototype.
Le format du fichier produit n'est pas compilable. Ce
fichier peut être utilisé comme sommaire d'un système.
3.4.4.5 Corrections au prototypes avant la génération
11
On peut omettre certaines informations lors de la
déclaration d'une fonction. L'extracteur ajoute ce qui
manque pour produire un prototype valide.
3.4.4.5.1Fonctions sans type de retour
Si une fonction est déclaré sans type, l'extracteur ajoute
'int' au prototype. La déclaration suivante:
max(int a, int b){....}
produit le prototype suivant:
int max (int a, int b);
3.4.4.5.2Paramètres sans type
Si un paramètre apparait sans type, le mot-clé 'int' est
inséré.
Soit la fonction suivante:
int max (a,b){ ... }
Le prototype produit sera:
int max (int a, int b);
3.4.4.5.3Fonctions sans paramètre
Le mot clé 'void' sera automatiquement inséré dans le
prototype d'une fonction sans paramètres, s'il n'est pas
déjà présent. La déclaration suivante produit:
int fct (){ ... }
produit:
int fct (void);
3.4.5 -C : Ne traite pas les commentaires imbriqués
Proto permet les commentaires imbriqués. L'option -C annule
ce comportement.
3.4.6 -d : Définition de symbole sur la ligne de commande
L'option -d permet de définir des symboles du préprocesseur
directement sur la ligne de commande.
12
L'option "-dsymxxx" est équivalente à la ligne "#define
symxxx".
L'option "-dsymxxx=yyy" est équivalente à "#define symxxx
yyy".
3.4.7 -e : Ferme un fichier résultat
L'option -e est utilisée après l'option -f (+f) et termine
l'usage de ce fichier comme fichier résultat. Il est donc
possible de produire en une seule session plusieurs fichiers
qui ont des contenus complètement différents.
Exemple: proto -ffichier1 a*.c -efichier1 -ffichier2 *.c
Ici, "fichier1" ne contiendra que les prototypes de fonction
des fichiers "a*.c". "fichier2" contiendra pour sa part
toutes les autres fonctions. Si l'option -e n'avait pas été
utilisé, "fichier1" contiendrait toutes les fonctions des
fichiers "a*.c" en plus de ceux contenus dans "fichier2".
3.4.7.1 Protection contre le double traitement durant une session
L'extracteur ne retraitera pas deux fois le même fichier
lors d'une session. Cela permet de traiter une série de
fichier avec une combinaison d'options et de traiter les
autres avec une autre combinaison.
La séquence suivante permet d'associer une combinaison
spécifique au fichier xyz.c.
proto -option ... -option xyz.c -option ... -option *.c
Bien que *.c inclue xyz.c, celui-ci ne sera pas traité deux
fois.
3.4.7.1.1Fichiers sources répartis dans deux répertoires
Une méthodologie applicable aux projets en groupe permet de
sauver de l'espace disque. Souvent les sources d'un projet
sont placés dans un répertoire référence. Le programmeur
importe dans un répertoire personnel uniquement les sources
qu'il modifie. Ce mécanisme est souvent réalisé par
l'éditeur qui lit les fichiers dans le répertoire référence
et les sauve dans le répertoire personnel lorsque modifiés.
Soit le projet X dont les sources sont placés dans le
répertoire /usr/src/x. Soit le programmeur 'prog' qui révise
le projet. Les sources sont importés graduellement dans le
répertoire /usr/prog/x.
La commande "proto *.c /usr/src/x/*.c" appliquée dans le
répertoire /usr/prog/x produira les prototypes du projet X.
La protection contre le double traitement est appliquée sur
le nom des fichiers et non pas sur l'accès (path).
3.4.8 -f/+f : identification d'un fichier résultat
13
L'option -f peut être utilisée plusieurs fois sur la ligne
de commande. En une seule session, proto peut produire
plusieurs fichiers.
L'option est suivi du nom du fichier qui sera produit.
L'option -f crée le fichier. L'option +f ajoute à la fin du
fichier.
Le nature du fichier créé dépend de la dernière composition
établie par l'option -c.
ex : "proto -cos -ffichier.p *.c" produira "fichier.p" avec
tous les prototypes des fonctions ordinaires et static du
répertoire courant.
3.4.8.1 Combinaison de l'option -c et -f dans une seule session
Les options -c et -f peuvent être spécifiées plusieurs fois
sur la ligne de commande.
L'option -c établie une composition de résultat valide pour
toutes les options -f qui suivent, et ce jusqu'à la
prochaine option -c.
La commande "proto -co -fordin.h -cs -fstatic.h -cod
-finfo.h *.c" produira trois fichiers de composition
différente. On sauve du temps à générer plusieurs fichiers
simultanément.
3.4.9 -h : fichier de prototypes C++ à décomposer
L'option -h commande la décomposition d'un fichier de
prototypes C++ contenant des fonctions membres (class
member). Autant de fichier que de classes rencontrés seront
produits. Le nom de ces fichiers sera obtenu en utilisant le
nom de la classe (potentiellement tronqué) suivit de
l'extension ".pp".
Ces fichiers pourront être sous-inclus dans les fichiers
d'inclusion déclarant les classes.
-h est suivit sans espace par le nom du fichier à
décomposer. -h sans argument commande la décomposition du
fichier ".pm" ayant le même nom que le répertoire courant.
La décomposition démarera après l'extraction du dernier
prototype.
L'option -h peut être utilisé plusieurs fois sur la ligne de
commande.
3.4.10 -i : Mode incrémental
14
Lorsque l'option -i est spécifiée, proto vérifie si les
fichiers à générer existent déjà. Si oui, il les relie.
Lorsque vient le temps de générer les prototypes d'un
source, il vérifie si ce dernier a changé depuis la dernière
génération. Les fichiers produits par proto contiennent la
date de chaque fichiers sources. Si les dates sont
semblables, le fichier source n'est pas traité.
Cela accélère significativement le traitement.
3.4.11 -I : Répertoire de recherche pour les fichiers d'inclusion
L'option -I indique la liste des répertoires à consulter
pour localiser les fichiers d'inclusion (directive
#include).
L'option -I peut apparaître plusieurs fois sur la ligne de
commande. On peut spécifier plusieurs répertoires en une
seule fois, en séparant ces répertoires avec un ':'.
ex: -I/usr/include:/include <==> -I/usr/include -I/include
3.4.12 -k : Renomme les mot-clés reconnus par l'extracteur
Certains mot-clés reconnus par l'extracteur ne sont pas
supportés par tous les compilateurs (export, PUBLIC,
PRIVATE, ...). Le programmeur doit donc fournir une
définition nulle au préprocesseur pour que la présence de
ces mots clés soit tolérée par le compilateur.
Ces mot-clés peuvent créés des conflits avec des noms de
variables ou de type déjà existant. Il est possible de
renommer ces mots clés ou simplement d'en annuler le sens
vue de l'extrateur.
L'option -kxxx=yyy renomme le mot-clé xxx à yyy. L'option
-kxxx annule le mot-clé xxx. L'option -k peut être utilisée
plusieurs fois sur la ligne de commande.
Soit l'exemple suivant où le verbe export entre en conflit
avec un typedef existant dans le programme. L'option
-kexport=EXPORT aura l'effet suivant: L'extracteur ne
reconnaitra plus le mot export comme un mot clé, tandis que
le mot EXPORT récupérera le rôle attribué normalement au
mot-clé export. Ainsi l'énoncé suivant sera acceptable.
EXPORT export *fct (void);
3.4.13 -l : Spécification d'un nom alternatif pour l'option -h
Lors de l'application de l'option -h, tous les fichiers
produits auront un nom composé du nom de la classe suivit de
l'extension .pp. Le nom d'une classe pourra être tronqué
pour satisfaire les limites du système d'exploitation. Il
est possible que deux classes entrent en conflit.
15
L'option -l force l'extracteur à utiliser un autre nom. Ce
nom pourra contenir ou pas un extension.
Ex: proto -m0+ -lCLASS_SPEC1=class1.pp
-lCLASS_SPEC2=class2.pp *.c -h
Les prototypes des fonctions membres de la classe
CLASS_SPEC1 se retrouveront dans class1.pp et ceux de
CLASS_SPEC2 dans class2.pp.
3.4.14 -m : Sélectionne une méthodologie particulière
-m0 : méthodologie pour projets à un seul répertoire
"proto -m0 *.c" appliqué dans le répertoire X est équivalent à
"proto -ceo -fX.p -ceod -fX.nap -ceoi -fX.nar *.c"
-m1 : méthodologie pour projets à plusieurs répertoires
"proto -m1 *.c" appliqué dans le répertoire X est équivalent à
"proto -ceo -fX.p -ce -f../include/X.p
-ceod -fX.nap -ced -f../doc/X.nap
-ceoi -fX.nar -cei -f../doc/X.nar *.c"
3.4.14.1 Répertoires alternatifs pour l'exportation des fichiers
résultat
Par défaut l'option -m1 exporte vers les répertoires
../include et ../doc.
Si le répertoire ../include n'existe pas, le répertoire ../h
est utilisé. Au moins un des deux répertoires doit exister
pour que l'option -m1 exécute correctement.
3.4.15 -o : Nom alternatif pour l'option -m
L'option -m compose le nom des fichiers resultats à partir
du nom du répertoire courant. L'option -o permet de
spécifier un autre nom
3.4.16 -p : Activation de l'extraction pour les fichiers suivants
Cette option est utilisée après l'option -x. Elle réactive
l'extraction des prototypes pour les fichiers suivants.
Par défaut, l'extraction est active.
3.4.16.1 Exemple d'utilisation des options -x et -p
Certains fichiers C ne comportent aucun prototypes
intéressants. Certains fichiers sont produit par des
générateurs d'écrans, de rapports, etc ... ne comportent que
des tableaux et constantes. Ces fichiers sont souvent très
gros. Il est intérressant de les éviter lors de l'extraction
dans le simple but de sauver du temps.
16
Soit les fichiers ecran1.c et ecran2.c que l'on veut éviter.
La commande "proto -x ecran1.c ecran2.c -p *.c" extraira les
prototypes de tous les fichiers sauf ceux-là.
3.4.16.2 Protection contre le double traitement durant une session
L'extracteur ne retraitera pas deux fois le même fichier
lors d'une session. Cela permet de traiter une série de
fichier avec une combinaison d'options et de traiter les
autres avec une autre combinaison.
La séquence suivante permet d'associer une combinaison
spécifique au fichier xyz.c.
proto -option ... -option xyz.c -option ... -option *.c
Bien que *.c inclue xyz.c, celui-ci ne sera pas traité deux
fois.
3.4.17 -P : activation du préprocesseur
Normalement proto ne fait pas l'expansion macro. Il ne fait
pas la lecture des fichiers d'inclusion. Cela permet à proto
de régénérer des sources (option -g) et aussi d'extraire les
prototypes très rapidement.
Généralement, le fait d'ignorer les commandes du
préprocesseur n'a aucun effet sur les fichiers produits. Il
existe quelques exceptions où le préprocesseur est essentiel
à la compréhension des déclarations.
L'option -P active un préprocesseur complet ANSI C
(construit dans PROTO). Les options -I et -d devront être
utilisées en combinaison.
L'option -g (régénération du source) perdra toute
signification.
3.4.17.1 Traitement des #define même lorsque le préprocesseur n'est
pas actif
Les définitions des commandes #define sont enregistrées même
si l'expansion macro n'est pas actif (option -P). Cela
permet d'évaluer les commandes #if, #ifdef, et #ifndef.
Les commandes #undef sont aussi interprétées dans le même
but.
3.4.17.2 Traitements des #if, #ifdef, ... sans -P
Lorsque le préprocesseur n'est pas actif, il n'est pas
toujours possible de sélectionner adéquatement la section de
code à analyser. Comme les fichiers d'inclusion ne sont pas
lus, la valeur des macros (#define) n'est pas toujours
connue. L'option -d permet de définir des macros directement
sur la ligne de commande.
17
3.4.18 -s : opération silencieuse
Normalement proto présente un rapport pour chaque fichier
produit, indiquant la composition (option -c) en vigueur
pour ce fichier.
L'option -s rend proto silencieux.
3.4.19 -t : lecture du source à traiter sur la console
L'option -t force proto à lire un source sur l'entrée
standard (généralement la console). Cela permet de faire des
tests rapidement.
La commande "proto -cxxxx -t" permet de vérifier le
comportement de proto pour certaines combinaisons.
3.4.20 -v : Liste des fichiers traités
L'option -v commande l'affichage de tous les fichiers
traités par proto.
3.4.21 -x : exclusion d'un groupe de fichier
Tous les fichiers spécifiés après l'option -x seront exclus
du traitement. L'option -p renverse cet état.
la commande "proto -x xxxx.c -p *.c" génère les prototypes
de tous les fichiers *.c sauf le fichier xxxx.c.
3.4.21.1 Exemple d'utilisation des options -x et -p
Certains fichiers C ne comportent aucun prototypes
intéressants. Certains fichiers sont produit par des
générateurs d'écrans, de rapports, etc ... ne comportent que
des tableaux et constantes. Ces fichiers sont souvent très
gros. Il est intérressant de les éviter lors de l'extraction
dans le simple but de sauver du temps.
Soit les fichiers ecran1.c et ecran2.c que l'on veut éviter.
La commande "proto -x ecran1.c ecran2.c -p *.c" extraira les
prototypes de tous les fichiers sauf ceux-là.
3.4.21.2 Protection contre le double traitement durant une session
L'extracteur ne retraitera pas deux fois le même fichier
lors d'une session. Cela permet de traiter une série de
fichier avec une combinaison d'options et de traiter les
autres avec une autre combinaison.
La séquence suivante permet d'associer une combinaison
spécifique au fichier xyz.c.
proto -option ... -option xyz.c -option ... -option *.c
Bien que *.c inclue xyz.c, celui-ci ne sera pas traité deux
fois.
18
3.4.22 Macros et Caractères spéciaux
Certains caractères et combinaisons de caractères auront une
interprétation particulière. Cela permettra de créer des
commandes générales dans des fichiers batch.
3.4.22.1 $ : Nom du répertoire courant
Le nom du répertoire courant est régulièrement utilisé pour
composer des noms de fichier ou de répertoire. Certaines
méthodologies spécifient que les prototypes d'un répertoire
doivent être placés dans un fichier portant le nom de ce
répertoire plus une extension.
Si on veut créer une commande générale, on doit pouvoir
automatisé la génération du nom.
Le caractère $ dans la ligne de commande sera remplacé par
le nom du répertoire courant.
"proto -co -f$.p -cod -f$.nap -coi -f$.nar *.c" sera
équivalent à "proto -m0 *.c".
3.5 Combinaisons invalides d'options
Plusieurs options sont disponibles sur la ligne de commande.
Plusieurs combinaisons n'ont aucun sens.
Certaines combinaisons invalides sont détectées et un
message d'erreur est spécifié. Certaines combinaisons
généreront des résultats complètement inutiles.
3.6 Stratégie d'utilisation de l'extracteur
L'utilisation de l'extracteur de prototypes est relativement
simple. On applique proto sur un certain nombre de fichier
source et on obtient un ou plusieurs fichier d'inclusion.
Beaucoup d'efforts ont été faits pour conserver à proto un
caractère général. Le nombre d'options disponibles en est un
témoin.
Nous allons suggérer une approche fonctionnelle applicable
autant au petit projet (1 seul répertoire de source) qu'à un
projet plus important.
3.6.1 Convention d'utilisation: Avertissement au lecteur
Les conventions qui suivent ne sont pas absolues. Nous les
jugeons acceptables et pratiques. Ces conventions
proviennent de l'expérience tirée de plusieurs projets de
diverses dimensions.
Les suggestions et améliorations sont bienvenues.
3.6.2 Le répertoire (directory) est la base de l'organisation d'un
système
19
Un système est généralement composé de plusieurs sources (10
@ 30). Un système complexe peut être composé de plusieurs
répertoires. En fait ce système est composé de
sous-systèmes.
Vu d'un client, un système qu'il soit complexe ou pas,
provient d'un seul répertoire. En fait, un client ne doit
pas savoir si un système est complexe ou pas.
Nous proposons donc qu'un répertoire corresponde à un
système. A ce répertoire sera associé une librairie (*.lib)
et un fichier d'inclusion.
3.6.3 Convention de noms pour les fichiers d'inclusion
Dans un but de simplicité d'utilisation et de réalisation
nous proposons une convention pour sélectionner le nom des
fichiers d'inclusion.
Le nom du répertoire sera choisi comme base du nom des
fichiers d'inclusion. Pour un système placé dans un
répertoire X, le nom des fichiers d'inclusions seront "X.*".
Cette convention vise les fichiers qui sont offert aux
systèmes clients.
3.6.4 Fichiers générés localement
L'option -m0 permet de générer localement 3 fichiers. Pour
un répertoire X, les fichier X.p, X.nap et X.nar. L'option
-m1 génère les mêmes fichiers en plus d'exporter trois
autres.
X.p contient les prototypes. Ce fichier sera sous-inclus par
le fichier X.h à l'aide de la commande '#include "X.p"'. Les
prototypes sont placés normalement directement dans le
fichier X.h. Ce fichier contient en plus des prototypes,
diverses définitions et déclarations. Comme l'extracteur ne
peut pas produire les prototypes directement dans X.h sans
en détruire le contenu, un autre fichier doit être produit
et inclus dans X.h.
3.6.5 Fichiers exportés pour les clients
L'option -m1 exporte trois fichiers en plus de produire
trois fichiers localement. Pour un répertoire X, un fichier
X.p sera produit dans le répertoire ../include et les
fichiers X.nap et X.nai seront produit dans le répertoire
../doc. En fait, ces fichiers portent les mêmes noms que les
fichiers produits localement. Ce sont des versions
restreintes (elles contiennent moins de fonctions) des
fichiers locaux.
L'utilisation du verbe 'export' au début de la déclaration
d'une fonction permet de spécifier les fonctions qui doivent
être offertes aux clients.
20
3.6.5.1 Le verbe export : extension au C
Le verbe export est un ajout au langage C. A notre
connaissance aucun compilateur C ne supporte un tel verbe.
Ce verbe est présentement appliqué à la déclaration de
fonctions, mais peut aussi s'appliquer à la déclaration de
types, de constantes, de variables, etc...
Le verbe export a un usage un peu équivalent au verbe
static. Ce dernier restreint la visibilité d'un objet au
source où il apparaît. Le verbe export, au contraire,
indique que la visibilité d'un objet dépasse le cadre du
système où il est défini. Une fonction 'export' est un
service officiel offert aux clients. Une fonction ordinaire
est local au système et ne doit pas être utilisée
directement par une fonction cliente du système.
3.6.6 Unicité du fichier d'inclusion
Pour un répertoire X, il existe un fichier X.h. Tous les
sources du répertoire X l'inclue. Ce fichier incluant
lui-même X.p, tous les sources ont accès aux prototypes de
toutes les fonctions du répertoire X. Le fichier X.h
contient l'énoncé '#include "X.p"'.
Si le répertoire X est un sous-système, le fichier X.h ou
une portion de celui-ci est exporté dans le répertoire
../include. Il devient disponible aux systèmes clients.
Lorsque qu'un source d'un système client inclut
../include/X.h, celui-ci inclut ../include/X.p.
Les clients ont accès aux prototypes de toutes les fonctions
'export' du système X. De plus, les fichier ../doc/X.nap et
../doc/X.nai peuvent être consultés pour obtenir plus
d'information sur le système X.
Le fichier X.h conceptuellement unique offre une vision
différente aux clients et aux sources du répertoire X.